Network Working Group J. Gargano 
Request for Comments: 1834 K. Weiss 
Category: Informational University of California, Davis 

August 1995 


Whois and Network Information Lookup Service 
Whois++ 


Status of this Memo 


This memo provides information for the Internet community. This memo 
does not specify an Internet standard of any kind. Distribution of 
this memo is unlimited. 


I. Introduction 


As currently defined, NICNAME/WHOIS [HARR85] service is a TCP 
transaction based query/response server, running on a few specific 
central machines, that provides netwide directory service to Internet 
users. The Network Information Center (NIC) maintains the central 
NICNAME database and server, defined in RFC 954, providing online 
look-up of individuals, network organizations, key host machines, and 
other information of interest to users of the Internet. The 
usefulness of this service has lead to the development of other 
distributed directory information servers and information retrieval 
tools and it is anticipated more will be created. Many sites now 
maintain local directory servers with information about individuals, 
departments and services at that specific site. 


Typically these directory servers are network accessible. Local 
development of these services has resulted in wide variations in the 
type of data stored, access methods, search schemes, and user 
interfaces. The purpose of the Whois and Network Information Lookup 
Service Working Group (WNILS) is to expand and define the standard 
for WHOIS types of services, to resolve issues associated with the 
variations in access and provide a consistent and predictable service 
across the network. This memo describes new features for WHOIS to 
meet these goals. 


II. Architecture 


The WHOIS service should be provided in a client/server model. There 
are no restrictions on the design of the client, provided it is 
capable of passing queries to the server in the proper format, and 
capturing the server’s response in some useful format. Existing 
WHOIS specifications call for clients to display responses in human- 
readable form. This more general proposal does not impose that 
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ELI; 


LV: 


restriction. 


This paper acknowledges the existence of many distributed information 
servers, and anticipates the creation of many more. To help users 
locate WHOIS servers, each server should have a nameserver entry in 
the form "whois.domain", i.e. whois.internic.net. 


Client Design and Behavior 


The client provides the user interface to the WHOIS system and a 
mechanism for query generation and display of the response. The 
client is responsible for providing support for paging of long output 
from the server. All clients must provide this service. The server 
will not include any special characters, or make any efforts to 
control output to a screen. 


Special search criteria may be specified by the use of keywords or 
special characters, some of which are defined in RFC 954. Clients 
should be designed to make support for quoted strings unnecessary. 


Server Design and Behavior 


The server should return the same information in response to a given 
query consistently, regardless of the client software or the hardware 
used to originate the query. Queries should be evaluated on a case- 
insensitive basis. Spaces should not be considered in searches. A 
search for "La Russo" should return both "LaRusso" and "La Russo" as 
matches. 


There are three types of data records supported in this proposal: 
records for people, hosts, and domains. 


Individual records 


Name Name of the individual required 
Organization Name of the organization required 
Organization-type Type of organization optional 


(university, commercial research) 


Work-telephone Work telephone number optional 
Fax-telephone Fax telephone number optional 
Work-address Work postal address optional 
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Title 


Department 


Email-address 


Handle 


Last-record-update 


Home-telephone 


Home-address 


Host records 


Hostname 
IPAddress 
Sysadmin-name 
Sysadmin-phone 
Sysadmin-address 
Sysadmin-email 
Machine-type 
Os 

MX 

Last-update 
Info 


Domain records 


Domain-name 


Network-—address 


Admin-name 
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Working title or position 
within an organization 
Department 


Email address in RFC 822 
format for this individual 


A unique identifier for this 
record on the local server 


Date this record was last 
updated 


Home telephone number 


Home postal address 


Full domain name 

Address 

System administrator name 
System administrator telephone 
System administrator address 
System admin. e-mail address 
Type of machine 

Operating system 

Mail exchanger 

Last update 

Location of additional 


information (i.e. anonymous FTP) 


Domain name registered with 
the Network Information Center 
(NIC) 


Network address associated 
with this domain name 


Name of the Administrative 
Contact for this domain 
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optional 


optional 


optional 


required 


required 


optional 


optional 


required 
required 
optional 
optional 
optional 
optional 
optional 
optional 
optional 
optional 
optional 


required 


required 


required 
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Admin-address 


Admin-telephone 


Admin-email 


Tech-name 


Tech-address 


Tech-telephone 


Tech-email 


Nameservers 


Last-—update 


Search Options 
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Postal address of the 
Admintistrative Contact for 
this domain 


Telephone number of the 
Admintistrative Contact for 
this domain 


Electronic mail address in 
RFC 1822 format for the 
Administrative Contact for 
this domain 


Name of the Technical Contact 
for this domain 


Postal address of the 
Administrative Contact 
for this domain 


Telephone number of the 
Technical Contact for this 
domain 


Electronic mail address in 
RFC 822 format for the 
Administrative Contact 

for this domain 


Primary domain nameservers 
for this domain 


Last date this record was 
updated 
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required 


required 


required 


required 


required 


required 


required 


optional 


required 


A unique handle must be provided for every record in the server 
database to target specific records for display. For 


there are three individuals named, respectively, A. La 


LaRusso, and C. Larusso, then a search for "LA RUSSO" 


all three as matches. 
handle, i.e. LARUSSO1, 


!SMITH1" 
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example, if 
Russo, B. 
would return 


However, each record would have a unique 
LARUSSO2, and LARUSSO3. A search for any one 
of these handles would return a single match for that particular 
individual. This is consistent with the RFC 954 query, "whois 
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Other 
whois 
whois 
whois 
whois 
whois 
whois 
whois 
whois 
whois 
whois 
whois 
whois 


whois 


whois 


whois 


whois 


whois 


whois 


whois 


whois 


whois 
whois 
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search options which should be supported are: 


smith 


smith, j 
"smith, j" 

j. Smith 

"3. Smith" 
smith, john 
"smith, john" 
john Smith 
"john Smith" 
-john Smith 
"smith..." 
smith* 
begins smith 


smith?? 


ends smith 
exact A Martinez 


fuzzy paulson 


first Kazuko 


first begins Art 


first fuzzy Kasuko 


hamlet .ucdavis.edu 


exact match on last name 


exact match first name 


begins with 


on last name, 
" gJ" 


exact match on last and first names 


all last names beginning 
with Smith 


all last names beginning with 
"Smith" and containing up to two 
letters after "Smith", i.e. "Smith", 
"Smithy", "Smithey" and "Smithie" 
all last names ending in "smith" 
exact match for "A Martinez" 


all last names that sound like or 
are spelled like "Paulson" 


exact match on first name "Kazuko" 


all first names beginning with "Art" 


all first names that sound like or are 
spelled like "Kasuko" 


IP address and other information 


system hamlet.ucdavis.edu on the computer called 
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hamlet.ucdavis.edu.Could be served 
by a domain name service querytype 
(QTYPE) * 
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whois system hamlet IP address and other 
information on the computer called 
hamlet with the default domain 
appended. Could be served by a 
domain name service querytype 


(QTYPE) * 

whois 128.120.2.9 domain name and other 

whois system 128.120.2.9 information on the computer at 
specified IP address. Could be served 
by a domain name service querytype 
(QTYPE) PTR. 

whois !ucdavis-—dom site contacts and other 

whois domain ucdavis.edu information on the site ucdavis 


If any keywords are specified in the query, the server will complete 
that specific query and return the results, even if 0 matches are 
found. If no keywords are specified, the server will interpret the 
query based upon the rules above. Optionally, the server may be 
configured so that if a search yields no matches, the query will 
automatically be run again, but with the keyword begin inserted. 


Servers must support multiple levels of detail in response to 
queries. A query yielding multiple matches should return a short- 
form record for each match. A query yielding a single match should 
return a long-form record. A query yielding no matches should return 
context-sensitive help on expanding the search criteria. 


On-line Help 


The client should return a minimal (two line) help message for every 
query sent to the server. That message should identify the database 
being searched and provide instructions for the user to obtain more 
detailed help screens. 


Additional help should be provided in special situations. The server 
should recognize queries that return zero matches, and provide a 
brief help message explaining how to broaden a search. If a search 
returns more than 50 matches, the server should take two actions. 
First, the user should get a message explaining how to narrow 
searches. Second, the user should be offered the option of re- 
specifying the search, or receiving all matching responses. When 
multiple matches are found and returned to the client, the server 
should add a brief help message explaining how to use handles to 
narrow the search to a single record. 
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VI. 


VII. 


If the client queries for "help" or "?" then the server should return 
a complete help file. The help file should contain information in 
sufficient detail for the user to understand and access all the 
features of WHOIS service. 


Extensibility 

This RFC defines a limited set of data records and fields for 
reliable whois queries. Mechanisms exist for whois clients to 
discover extended data records and query for fields not defined in 
this memo. It is recommended that Whois clients and servers include 
this functionality to maximize the extensibility and usefulness of 
this service. 
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Security Considerations 


Security issues are not discussed in this memo. 
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